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(57) An electronic ibijidge; resource; management 
system, having aj; jprc^ammfetjcal^ 
processing system. A bridge, Service interfaces with- a ? 

plurality of clients and receives a quality ^of service;, • < "mpdules, and then determines whether bridge resourc- 



straint associated "with the QOS specification across, 
flow processing modules of a channel, determines re- 
source^ requirements for each of the flow processing 



(QOS) specification (4H rom each of the clients. A re- 
source manager recejyes a QC5S specification (5) from 
the bridge service, distributes *at least 'one QOS con- 



es can be allocated to meet the QOS specification. The 
clients may alter their QOS specifications and retry if the 
resource manager denies them admission because of 
a lack of available bridge resources. 
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Description 

Field of the Invention 

The present invention relates to a system for effi- 
ciently allocating broadband bridge resources.ln partic- 
ular, the system allows client applications to negotiate 
quality of service contracts with a bridge resource man- 
ager. [ '.; 

Background of the Invention 

As the deployment of high-speed networking accel- 
erates to reach homes and offices, the popularity of mul- 
ti-user applications is expected to increase dramatically. 
Examples of these applications include conferencing, 
game playing, collaborative working and distance learn- 
ing. Multi-user applications usually involve different in- 
formation types, such as control data, video, images and 
audio, which are exchanged between the various user 
terminals, i.e., they are multipoint. Designing a system 
to support these multimedia multipoint applications 
presents two key challenges: a scalable technique fpr 
managing potentially complex interactions, and the : use ' 
of resources in an efficient and economical fashion. In 
the Narrowband-ISDN context, these issues are ad- 
dressed for multi-user conference calls by using a 
bridge; also known as a multipoint control unit (MCU)f * 
A bridge is a logically centralized service that performs 
data combination and conference management,- e.g., 
adding/dropping users. It accepts audio from each of the 
users, mixes the signals and transmits the resulting sig- 
nal in return, thereby enabling multipoint communication 
over point-to-point links. 

in a packet based neiwork like Broadband-ISDN, it 
is of course possible to provide these bridge functions 
in a distributed manner at sophisticated terminals, e.g., 
personal computers (PCs) and workstations. However, 
there are cogent arguments for the use of a bridge in 
this scenario also; Simple terminals will continue to be : 
attached to the network and may not be capable of sup- 
porting these functions. Directly attached ATM devices, 
as well as telephones, fail in this category. By providing 
a logically centralized focus of control, many of the man- 
agement issues are simplified, notably with respect to 
maintaining accurate state information and 1 providing 
secure access. Regarding the use of bandwidth, a 
bridge-based solution can be highly efficient,- avoiding 
any unnecessary data transmission. For example, one 
doesnl need to receive individual (bandwidth intensive) 
audio and video channels from each user.' 

Designing a broadband bridge is considerably more 
complex than for the- narrowband network and raises 
several issues which must be addressed in order to 
make this approach viable. The focus of the present in- 
vention is on how to efficiently manage bridge. resourc- 
es, an issue which is motivated by the following four con- 
siderations. Firstly, the range of applications is much 



wider, demanding a greater flexibility in terms of bridge 
functions and the resources they demand! Secondly, the 
capabilities of terminals will vary as will the, types of , 
• ! compression and data channel processirig 'that they 
5 support. Thirdly, use of a packet netwbrk ir> combination 
\ ■ ' with variable bit rate traffic such as compressed video, 
introduces issues of bridge resource- management akin 
to those for the network itself. Fourthly, operation of the 
bridge can have serious consequehces fof- the end to 
io end Quality of Service (QOS) received by audio and vid- 
eo channels, notably in regard to delay and packet loss. 

Summary of the Invention ' 

is A bridge provides sTset.of services, tb.eriable effi? 
cient operation of multipoint application^. |Jn, a broad- 
band context, the task of designing a multipoint bridge 
is complicated by several factors; ihcludinc/diff erent me- 
dia-types, asynchronous (packet) communications, and : 
20 ' heterogeneousUerminals.' The present invention is di- 
rected to resource management within a broadband j 
multipoint bridge/ ; , - -,^ v , >. r: ^ - • , ^ 

According to one aspect 'of the invention, an elec- 
tronic bridge resource management system comprises p ■ 
25 ' a programmatically-implemented prbc'essihg system " 
~- having bridge service and resource manager software? : 

The* bridge service 1 interfaces^ with a plufality of clients 
* : and receiveVa quality of service (QOS)* specification^ 
from each of the clients. The resource maihager receives 
30 the QOS specification from'the bridge*service : and dis- 
tributes at least 'one QOS constraint associated with 
said QOS specification across the flow processing mod- 
ules of a channel. The resource manager then deter- 
mines the resource requirements for each of the flow 

sources can be allocated to meet the QOS specification. 
As part of the QOS contract negotiation process, the cli- 
ents may alter their CiOS~ specifications and retry-if the 
resource manager denies them admission because of 
a lack of available resources. - 

According to a second aspect of the invention, a 
method is provided for implementing" a bridge degrada- 
tion policy where a client passes service degradation 
policy information to the bridge- The degradation policy 
infdrmation relates to a prioritization amongst either cli- 
ents, : channels, or groups* The bridge then stores data 
corresponding to the degradation policy information in 
the appropriate client, channel or group data structure. 
The bridge implements the specified degradation policy 
should a bridge resource overload occun 
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Description of the Drawings 

The invention' will be described in greater detail be- 
55 low with reference to the attached drawings, of which: : 
Figure 1 is a diagram showing a typical bridge sys- 
tem' configuration. ■ ' , . ; v 
Figure 2 is a dia'gram showing an example of &dj£- ] 
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tributed bridge. 

Figure 3 is a functional block diagram illustrating the - 
overall bridge architecture. , ' f 

. Figure 4 is a diagram illustrating the basic FPMs 
and flows for a single (audio) channel, two client confer- < ' 5 : 
ence. - _ : 1 

•Figure 5 is a diagram showing several examples of 
multiport FPMs. 

Figure 6 is a diagram illustrating the components of . 
the bridge software architecture for QOS management. - to 

Figure J. is a charUIIust rating interactions between 
clients and bridge for forming a three client audio con- 

ference. t , v * i ' 

. . .j . 

V 

Description of the Preferred Embodiment ] 75 

-.-.Jn^the-following description of ( .the preferred embod- 
iment a- "-group" refers to acoliection of clients that par- 
ticipate in multi-us.erapplication. : Fpr each group that ; 
the bridge is asked, to create, rt maintains a data struc- . 20 
ture.. ct : _ m } - nv-^.v *c r--^-~; . ■ : -;. 

A client is a software program that runsat a mutti- 
medja germinal ^nd interacts wrt&tbe^.brjdge service Jto • 
allow a user to-take par>in a gr,oup,Jnjorder to participate 
in a ^a^iGul^ismufti-user^pplication^ a t user is expected 25 
to seJe^and^run the-corf esppnding client program. For . * 
example ajuser could participate in a multirplayer game 
and ; a?mu^-user;popference py running both . the game r . 
and conferencexNer^ recorded in 

a brjdge-raajntair^ed data structure. : ^ : - 30 

,4 Associated .with a group are one or more, channels, 
where each channel aHows communication of a specific 
information type -between the clients in the .group. Ex- 
amples 9f;informat[on : types are audip, video and white- 
board data. A channel is-represented by a bridge-main- 35 
tained-data structure and realized, using a set of dedi- 
cated flow processing modules (FPMs) and connecting 
flows ^escribed ip detail later). For an audio conference . 
wittMhree clients, for example, the channel consists of 
a pair of flows for I/O to each client and an audio mixing 40 
FPM at the bridge. ; - :H . . s !V 

. JEaph use,r participates jn a group by interacting with - 
a b/idge using-his/her terminal, typically via a graphical - 
user. .interface (GUI-), Terminals may take many forms, 
including Pps antfset-top boxes, and are equipped with 45 
broadband network access and some I/O devices, such 
as a display, speaker, microphone .and/or a camera. Ap- 
plication software, running on the terminal or its agent 
(e.g., a PC controlling access to a telephone) .uses a 
signalling protocol such as remote procedure call (RPC) .. so 
to interact with the bridge service. 

The bridge service is software running on the bridge. , - 
to implement the application' programmer's interface" 
(API) .to the services provided, by the bridge. A bridge is 
designed to allow simultaneous access by multiple . 
groups. .The -broadband network is used to transport 
control information (i.e., signalling) and data traffic over- 
virtual. circuits between the bridge and terminals. Data 
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traffic includes continuous media (CM) such as audio 
and video, which may be used depending on particular 
application requirements, usier preferences 1 and Jerrrii- ' 
nal capabilities. '. * ** 1 i " 

Figure 1 - shows a typical system j configuration 
where a bridge 10 and various multimedia terminals 12 
are interconnected by a broadband ATM network 14. A 
bridge is a computer system designed to handle large 
' internal and external data bandwidth, 'such as available 
on modern class server machines (e.g., Silicon Graph- 
ics Inc. Challenge servers). A network service! provider 
may implement a bridge server- as 'a switch adjunct iri 
ah intelligent network. The bridge 10 may be physically 
realized using a collection of networked hosts, offering 
perhaps, media-specific facilities t such as video 
processing. Such a. distributed bridge arrangement is il- 
lustrated in Figure 2 where a bridge service host 16, a 
video processing host 1 8, an audio processing host 20, 
and a data processing host 22 are interconnected by the 
broadband network 1 4 itself. Moreover, the concepts of 
the present invention could also be supported by multi- 
ple cooperating bridges. 

The bridge service API allows user applications (cli- r 
ents) to access the facilities of a bridge 10. When a re- 
quest is received by the bridge service it is processed 
and a reply is. returned to the client, indicating success 
.or failure -As part of processing each request the bridge . ^ 
service may initialize or modify state information which ; 
it maintains to record information about groups and cli- 
- ents. The interface to the bridge 1 0 is defined by the API ; 
and associated state information. The interface might 
also support multilevel groups (e.g., to allow sub-con- re- 
ferences). _ v 
As already defined, a group refers to a collection of ?> 
clients that participate in a multi-user application involv- 
ing a bridge 1 0. For each group, the bridge service main- 
tains a data structure as part of its state information. It 
also maintains per-client information, with a distinct cli- 
ent.data structure for each group in which a user partic- 
ipates. These data structures maintained by the bridge, 
and their constituent fields, are as follows: 
Group Data Structure 

1 . group identifier 

2; list of current clients (i.e., the participants) 
-3. group owner (the creator by default) 
A current status (e.g., starting, ongoing, paused, fu- 
ture reservation) 

5. schedule (start time/date, duration) 

6. floor control policy (e.g. , open, selected client co- 
ordinates, bridge coordinates requests sequential- 

: iy) 

7. accesscontrol policy (e.g., open, restricted client 
c list) 

8. setup mode (active - bridge initiated, passive) 

9. billing (e.g., owner, equal client shares, usage- 
based) 

- .10. media channels (number and type;-e.g ; , video, 
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audio, whiteboard) 

* 

Client Data Structure \ . ., 

i • 

1; client identifier & 

2. user details (name, address) . ■] 

3. client address 

4. authentication key (cryptograph jc key) 

5. current group (can be nulj) > , . 

6,. current status (active/inactive) . ! no 

7. event reporting (on/off, event mask) ' : , 

8. acceptable data formats (compression, coding) t \ ( 

9. available media devices (types, capabilities) J 

10. list of current channels , , < 

11. media channelmask . ; Tf 

12. presentation options (e.g., window quadrants, 
audio-based selection) f ; 1 

Several parameterized calls are provided as part of .; 1 
the -API, including those to: (1) create and destroy a 20 
group; (2) create and 'destroy a client; (3) allow a client 
to join or leave a group; and (4) set or get attributes of 
a group or client. i . i , 

As illustrated in Figure 3, the bridge architecture 
comprises three basic elements; the bridge service 24, 2s 
channel processing 26, , and .network access 28. The 
bridge service 24 implements the API and grants bridge 
access to clients, groups and channels. Some of the 
channels being used in a group may require processing 
by the bridge 1 0 (the channel processing function 26 in 30 
the present invention is performed by the FPMs). In par- 
ticular, CM may be operated on to perform synchroni- 
zation, combination and/or transformation. Synchroni- 
zation is essential so that temporal relationships be- 
tween CM can be maintained. Combination refers to 35 
functions which can be applied to a set of CM, e.g., in- 
dividual gain controls for audio, and image scaling for 
video. The need for transformation arises due to the use - 
of heterogeneous' data formats and device capabilities. , 
For example, one multimedia terminal might have an 40 
MPEG compression board while the other participant 
has only. JPEG support. The bridge must also access 
the broadband network 14 in order to receive and transv . 
mit control and data (including CM), and execute the ap- 
propriate communications protocols.. For example, the 45 
network access function 28 of the bridge supports BIS- 
DN signalling, AAL/ATM processing, and data transmit/ 
receive. 

An important requirement in operating a bridge 10 
is performance. In other words, how to give clients ac- so 
cess to a group with a level of performance that is ac- 
ceptable and predictable. This in turn demands an ap- 
propriately designed resource management system. In 
the narrowband case this is drastically simplified by the 
fact that the maximum bandwidth is lowr even for CM, 55 
and the current usage easily determined by the number 
of active physical network connections. In addition/the 
set of processing functions is usually quite limited. and 



statically defined, allowing implementation using a bank 
of DSPs. For a broadband bridge, however, the set of 
processing functions will be larger and will need to be 
, capable of being dynamically updated, e.g:, to accom- 
modate a new video compression, format. This places 
an increased emphasis on software implementations. 
Furthermore, the maximum bandvyidth will be significant 
and, more importantly, may vary even for a given -CM 
channel, making it more difficult to determine .current us- 
1 age requirements. The .present invention therefore pro-- 
vides an efficient .technique ;^or managing access to 
bridge resources. ■_• - ; , V , r>\ - : ; • ,v • / 

1 In essence, a bridge 10 is a server in a large dis-, 
tributed computing system. : The conventional way of 
, dealing with resource management in §uch systems:is 
to rely on an operating system , to control resource ac- 
cess by a collection of user-level enfitiesi often called 
processes or domains. This_ allows the processes tqop- 
erate. independently but, share a common platform. For 
a broadband bridge;this could take the form of a bridge 
service that instantiates^ process to deal with each new. 
group. That process would then deal with its;client's re- 
quests] and perform channel processings and^distribu-; 
tion. Each process would make requests, to the operat-. 
ing system in order to access resources,. such as CPUs, 
DSPs, memory and network I/O. While this is a reasons 
: able model,: it makes it difficult to allocate, resources in^ 
a manner which is.both effiqient and c^nensure predict- 
able scheduling. For a broadband bridge,;a>finerdegree^ 
of resource management is desirable.- This is- important, 
in order to support the Quality of Service (QOS) require- 
ments of CM channels, which typically have stated de- 
lay,- jitter and.loss tolerances. * ; ; -j. 

In general terms, a QOS contract is an agreement 
with a resource provider for use of that resource to sat- 
isfy a specific performance requirement. QOS defines 
the expected performance for data transport on a flow. 
It is specified as a set of parameters describing the type 
of QOS contract, traffic and performance. Broadband 
. networks are designed to support QOS contracts on an 
end to end basis. In the system of the present invention, 
these contracts are extended to encompass bridge op- 
eration; - 1 •: 

An architecture for QOS has. a set of basic, func- 
tions: specification negotiation, translation, admission 
control*, policing and scheduling. User specifications de- 
scribe; traffic . characteristics (e.g., mean/peak band- 
width, burstiness), performance requirements (e.g., de- 
lay, jitter, losses), and type of.QOS contract (e.g., guar- 
anteed, statistical); In order to try to ensure that these, 
QOS requirements can be attained, a user must nego- 
tiate with a QOS manager. This- entails passing the 
specification information and waiting to see if access will 
be granted or denied. The specification is translated by 
the QOS manager to a set of resource demands, e.g;,: 
amount of memory'and CPU cycles, and used in com- 
bination with knowledge of already existingjapplications . 
to perform an admission control test. The result; deter;; 
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mines whether a QOS contract can be established for 
use of the system as requested- If a contract is granted, • 
a policing mechanism aims to ensure that the stated 
source traffic limits are upheld, while the scheduling 
mechanism aims 'to try and meet performance require- 
ments. ' 

I n order to allow QOS-driven resource management 
for^ broadband bridge 10, the system^ of the present 
invention allows clients to establish contracts for bridge 1 . 
access in a similar manner as they; do for network ac- ' 
cess. Furthermore, rathef "than 1 simply allocating re- 
sources based on number of groups, clients- or chan- , 
nels,' higher efficiency is : achieved by' associating re- ! 
sources with - channel processing activities;. Such re- 
source allocation is enabled by introducing the concepts 
of "flows" and-"flow prdcessirtg modules"> v. |\ 

Recall that a group may ; involve several channels, 
some of whictvmay -carry CM. Each client Will contribute 
to, and recefrersorrfe or aH df the^ chanhels in its group. 
ThusVfor a given chanheh the bridge 1 0 wiftbereceiving 
data from clients,' operating oh it.^and-retuming the re- 
sultihg^dfita. An exfcmp!e~is a group' which has a single ; 
channelover Which ea'Ch client transmits -Its audio and * 
receives thelcombined^ignal in return, s • i 

'^"ffow^ istthe connection* for carry tag data from/to 
a dienvand the; connection for ■carrying data internally 
between the chanhel^p'rccessing stafges 26 of the bridge 
1 0. Each chanhePcorfiprise&a' sel oil lows/ A f low Is al- 
ways associated with "a particular channel within a 
group, but hot ne6essarify a- single client; of that group. 
Essentially, >a flow is a^ Unidirectional' pipe for data trans- 
port between ports thatis implemented using a network 
virtual circuit (VC) or internall/to the bridge 10; by using 
bridge memory-buffers^ ~ *- 

The various functions 26 that can be applied to a 
channehare -realized Using flow processing modules 
(FPMs), which could be implemented as functions in a 
programming language library. Each one of these im- 
plement a single well defined J unction .and execute at 
run time as<< independently sehedulable .threads. A 
thread is -a software program that exists to execute an 
FPM instance or process a flow within a client. Thus, 
once a given FPM is selected, an instance of that FPM 
is created and assigned to a thread for. execution. 

Each FPM is designed to receive- data* f or a partic- 
ular channel on one ormore input flows, process it to 
perform a self-contained function, and then transmit the. 
resulting data on its-output flow(s). A simple example of *' 
a FPM is one whicrYis responsible tor receiving flow data 
from. : an incoming" network VC. .Mope sophisticated ex-' 
amples include FPMs fonoombining audio and perform- ' 
ing video format conversions. As part of its definition, a 
FPM may accept parameters which tailorJts behavior. 
For example; a JPEG video, compression. FPM would 
accepfa quantization factor. 

Each FPM performs soft ware initialization and core 
processing. Once an instance of an. FPM is created, it 
performs initialization which involves interpreting control 



parameters, setting up data structures, etc. The FPM 
instance then enters a loop where its core processing 
i ■ takes place. In particular, this is a loop in-whicli the FPM 
reads data from its input flow(s), processes it' and writes 
5 > "the results to its output flow(s)! Core processing may be 
implemented in different ways independent of the FPM's 
functional definition. For example, an audio combination 
. FPM may be executed on a CPU or using a DSP. Tra- 
; d it ion ally DSPs have been used to support audio and 
to image manipulation, but with faster processor speeds 
and suitably designed compression techniques it is pos- 
'• sible to implement many such features in software (eJ 
g., a video mixer) thereby facilitating the incremental ad- 
dition of new bridgefunctions. ' 

15 Software allocates bridge resources to each FPM 

j i.t t 

instance admitted for execution. Such allocations are an 
important aspect of the present system. It is by control- 
ling how each thread accesses the bridge resources that 
QOS contracts can be honored. 

20 Figure 4 shows the use of FPMs to implement a two 
client conference with just a singtef (audio) channel, 
where client A 30 and client B 32 communicate via the 
bridge 1 0. Two FPMs 34, 36 are used for receiving audio 
information and two FPMs 38, 40 are used for transmit- 

25 ting audio information. Flows 42 carry data to/from the 
bridge and interconnect the FPMs for a given channel. 
Data is processed in a pipeline, arriving from the net- 
work and traveling on flows through a sequence of 
FPMs/ - -* ' •:■ 

30 FPMs are allowed to have more than one input and 
output port. A port is an end-point for communication 
over a flow. It is associated with a particular thread, run- 
ning on either the bridge or a multimedia terminal. Figure 
5 shows four examples of multiport FPMs: a Convert 

35 FPM 44 having a single input and output port; a Syn- 
chronize FPM 46 having two input ports and two output 
ports; a combine FPM 48 having two input ports and a 
single output port; and a select FPM 50 having two input 
ports and a single output port. Each FPM also has con- 

40 trol and feedback ports for interacting with the bridge 
service (not shown). 

The FPM/flow model requires extensions to the 
bridge service API and state information as previously 
presented. Data structures for a channel, flow and FPM/ 

45 Thread are as follows: 

Channel Data Structure 

1 . channel identifier 

2. channel type (e.g., audio, video, data, animation, 
50 etc.) 

3. owner (e.g., group identifier) 

4. list of flows (flow identifiers) . 

5. list of FPMs (module" identifiers) 

55 Flow Data Structure 

l. flow identifier 
" 2. owner (default is group) - , ■ 
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3. source (host/th read/port) 

4. sink (hostAhread/port) 

5. network VC information (e.g., ATM address, uni- - . / -f 
cast or multicast VC) , ! . i / 

6. QOS (contract type, traffic, and performance) 5 

FPM/Thread Data Structure 



1 . module identifier 

2. owner (default is group) ! i 

3. control/event ports 

4. list of input ports . .. ;l 

5. list of butput ports } ■ . ! 

6. operating parameters 5 

7. resource handles (a "ticket" allowing access to 
allocated bridge resources) 



10 



75 



Access to the above items is achieved by extending ' ; 
the API with the following parameterized calls: (1 ) create 1 
and destroy a channel; (2) join and leave. a channel; and 20 
(3) set and get channel attributes, L 

The FPM/flow model aims to simplify the process ■ 
of translating a client's requirements for service quality ( 
and bridge functions in terms- of actual resource needs. 
As mentioned, resources are allocated so that a thread 2s 
can execute an instance pf an FPM. In the bridge, these 
resources (represented in Figure 6) are memory 52, 
DSPs 54, CPUs 56, internal and external, bus/network ! 
access 58. Other resources used to transport or process 
data may also be allocated, e.g., switches. 30 

Figure 6 shows the components of the software ar- 
chitecture, needed for resource management within a 
bridge. Access to the bridge is by way of the Bridge 
Service 60, which passes requests on to the resource 
management system. There are three levels of resource 35 
management, the lowest being the individual resource 
schedulers 62, which allow access to resources by 
those. FPMs admitted for execution.. A resource sched- 
uler selects from amongst waiting FPMs according to a 
scheduling policy. In order to allow performance con- *o 
straints to be satisfied, a scheduling algorithm of the 
type used in fast packet switches is employed, i.e., sup- 
port for priority and time deadlines. At the middle level. . 
are three controllers, defined for synchronization SA y 
combination 66, and transformation 68 FPMs, . one for- 4S 
each of the three types of processing that the bridge im- 
plements. These keep track of the available FPMs and 
can estimate their resource requirements for a given pa- . 
rameter and traffic set. At the top level is the QOS Man- 
ager 70. This can be viewed as a higher-level scheduler : so 
which performs admission- control and coordinates re-, 
source access. A resource handle is an identifier issued 
by the QOS Manager 70 for use by an FPM to gain ac- - 
cess to a particular resource. This- is achieved by pre- - 
senting the handle to the appropriate resource schedul- . ss 
er 62. At the same level as the QOS Manager 70. is.the 
Reservation Manager- 72; which allows longer term * 
management by handling advance reservation of bridge 



resources. / 

In order to explain the detailed interactions of the 
three levels of resource management, an example will 
be used. A three client audio-only conference and the 
varipus interactions necessary to realize it is shown in 
Figure 7. the owner makes a request (1) to the Bridge 
Service 60 to create a client which we call Client A, and 
subsequently to create a group' (2) that will have a total 
of three clients, a single audio channel, and which is to 

' start immediately. The bridge service 60 allocates and 
initializes client and group datd structures; returning an 
indication of success to Gljent A; plient A then requests 
(3) that the channel be created, and that a FPM for audio 
combination Should be associated with it. If successful, 

; the channel data structure and a FPM data structure (for 
the : audio combination FPM) are created by the bridge 
service. Client A then requests (4) to join that channel, 
supplying theQOS;parameters.(i.e., the QOS specifica- . 
tion), it ( expects for the flow to be received fr9m the 
bridge. . ^ : , - . ■ - . - -!...■:■'.■/ 
It is at this point that the Bridge. Service 60 calls (5) , 
on the QOS Manager 70 to decide; whether thecjient; 
should be admitted for execution.- Admission control irv 
volves three, basic steps: constraint ; distribution, re- 
source translation,, and admission decision., Qpnstraint; 
distribution involves a soft ware algorithm for decompos-/ 
ing the overall QOS constraints (as. given in the speqifK 
cation) in terms of operating constraints; for the individ^ 
ual threads which are executing FPMs for that : channel. 

. Various approaches can be used for implementing con- 
straint distribution. One approach-is to simply distribute 
the .constraints equally. A more sophisticated approach 
corresponds to a two phase protocol used for virtual cir- 
cuit establishment in some wide area ATM networks. In 

* the first phase the network QOS specification is passed 
sequentially through each switch between the source 
and sink, aiming to satisfy the overall constraint at each 
switch. The second phase proceeds in!. the reverse di- 
rection and attempts to optimize the constraint distribu- 
tion. A result of such an approach is that, for example, 
a heavily loaded switch can be given the freedom to in- 
troduce a larger delay than others which may be more 
lightly loaded: . : , 

After constraint distribution, the translation feature 
- is implemented to determine the resource requirements . 
of the. FPMs for the specified constraint distribution. 
Translation- is: the act of determining approximate re- 
source requirements for each thread sothaUtcan meet , 
its assigned QOS constraints. In the present example, 
the QOS Manager 70 calls (6) on the combination con- 
troller 66 to assess what type and quantity of resources 
are- required for the FPM based on, the QOS require- 
ments of Client A's audio. It then uses this in combina- : 
tion with the resource requirements for the receive and 
^transmit FPMs* to reach an initial admission decision. If 
insufficient resources are available, then the QOS Man^ 
ager 70 tries a different constraint distribution and re-, 
peats the translation step.. Itthere are sufficient resourd- ; 
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es the QOS Manager 70 checks (7) with the Reservation 
Manager 72 to ensure that the resources it is about to 
allocate arent already reserved. If they are in fact avail- 
able for immediate use, the resources are allocated and 
marked in the QOS Manager's state tables as allocated. 

The QOS Manager 70 then instantiates the combi- 
nation, receive, and transmit FPMs and updates the 
channel data structure! (The receive and transmit FPMs 
are automatically created when a client join's a channel. 
Similarly, any transformations required will automatical- - 
ly result in a transformation-FPM being-created and ex- 
ecuted basecf on the client's capabilities as determined'* 
from-the client data structure.) The interconnecting flows 
are then -created as -follows: (a) the QOS Manager 70 
sends a control message to the audio combination FPM 
requesting its desired Input port number; (b) when this 
information is received, the QOS Manager 70 sends a 
control message to the receive FPM (via its control port) 
specifying the thread identifier and port number of the 
audio combination f PM to which it should send data; (c) 
the receive FPM also reports its output port number; (d) . 
the QOS r> Manager 70" dan now initialize a Flow data 
structure* be caused has the thread and port information 
for the flow's sodfce and sink. Ir> a similar manner,, the 
GGS*Maflager' 70- interact^ With- thte transmit 1 FPM and 
then the audio combination FPM to-derive the relevant 
portMntormatibrf and initial ted* "the 'data ^structure for then, 
interconnecting flow. 1 vr " - - - & 

Irf-performing- the- preceding steps? flow and FPM/ 
Thread data structures are^created and- initialized. -The 
QOS field in feacrvflow data-structure infilled in depend- 
ing bn theiconstraint decomposition decided upon by the 
QOS^Marfager 70 during constraint distribution. In par- 
ticular^ the constraints assigned to each thread deter- 
mine athe corresponding QOS parameters that are 
stored as part of each flow data structure. Combining 
QOS fields in all the flows of a particular channel should 
equal the overall QOS specification provided by the cli- 
ent. Note that the FPM data structure includes the han- 
dle of the specific resource(s) which have been allocat- 
ed to it, and such resource(s) include the flow. resources 
(VC or buffers) connected to its output ports. 

A reply (8) is then sent to the Bridge Service 60 
which in turn gives to the client (9) details of the bridge 
port (of the receive thread) to which it should open a VC 
for the audio data, and the QOS parameters it should 
request from the network for that VC (for setting up net- 
work contracts). 

In asimilar manner, both Client B (1 0) and Client C - 
(1 1 ) also make requests to create clients, join the group ' 
and channel. In response to the request to join the chan- ~ 
nel, the QOS Manager 70 performs an admission con-, 
trol lest using the client's QOS parameters (these, are 
provided to.the bridge- for each channel that, a client *. 
wishes to join).and the expected. increase in the FPM's 
resource needs. * As each, client joins a channel the 
bridge also arranges its network transport (i.e., creating . 
a VC.for flow data) to that client over a unicast or multi- 
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cast VC. Note that the QOS Manager 70 uses the control 
port on the combination FPM to arrange for it to handle 
an additional flow of audio. Any subsequent, requests to 
modify attributes which may affect resource usage are 
also passed by the Bridge Service 60 to the QOS Man- 
ager 70 for evaluation. Should a request be denied be- 
cause of a lack of available resources, a client may alter 
its request and retry. , 
Once' a client is admitted to join a channel, data will 
flow .between threads requiring that the threads execute 
in order to process trie data. 1 Resource schedulers 62 
select from amongst those threads that are ready to ex- 
ecute (at any point in time a resource scheduler has a 
queue of threads eligible to execute). The resource 
scheduler 62 selects the thread to execute next based 
on some policy and after examining the resource han- 
dles belonging to the waiting threads. Such a policy, for 
example, might be preemptive time-sharing or earliest 
deadline first. Finally, in the case for example of an al- 
, located CPU resource,, the resource scheduler 62 loads 
the thread state into the CPU's registers and then starts 
it executing. ' h 

Advance Reservations 

The basic QOS model corresponds to that used in 
the ATM networking area. A characteristic of that model 
is that a QOS contract is negotiated for immediate ac- 
cess to resources and for an unspecified length of time, 
equivalent to making a telephone call. For many of the 
applications that a bridge -supports, notably conferenc- 
ing, this model is not always appropriate. Use of such 
applications has a parallel with real scenarios, where for 
example, it is common to schedule a meeting in ad- 
vance. The ability to make an advance reservation for 
use of a bridge 1 0 is a feature implemented by the Res- 
ervation Manager 72 depicted in Figure 6. 

In order to make an advance reservation, two pa- 
rameters are needed: start time and duration. The start 
time indicates either an immediate start (the default) or 
some future occasion. A duration defines the maximum 
time length and is necessary for both immediate and fu- 
ture requests so that the bridge 10 can capitalize on re- 
source sharing and utilization. Note however that both 
* of these parameters can be renegotiated; analogous to 
changing the meeting time or extending its length if the 
room is available. These parameters were described as 
part of the group data structure and are passed as part 
of the call to create the group. A key issue here is figuring 
out how much resources will be needed, as this is nor- 
mally done as each client joins a channel. The accuracy 
of this process depends on how much detail the reserver 
can provide. The Reservation Manager 72 uses that in- 
formation to derive an estimate. As a minimum the re- 
server is expected to indicate the number of clients 
which are expected to participate in the group and the 
channels to be used. This allows for the use of transmit 
and receive FPMs as well as interconnecting flows. If 
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the reserver indicates additional FPMs then the esti- 
mate can be improved. 

In terms of the resource management architecture 
a set of interactions are involved. When the Bridge Serv- 
ice 60 receives a request with a future start time sped- s 
fied it makes a request to the Reservation Manager 72. ■ 
The Reservation Manager 72 operates by building up a 
resource request based on the information provided by 
the reserver. It consults with the FPM controllers 64, 66, 
66 to provide resource estimates, and then checks with io 
theQOS Manager 70 to determine any overlap with cur-. - 
rent allocations. At this point, a reply is sent to the re- , 
server indicating whether the necessary resources will 
be available. If the reserver subsequently provides ad- 
ditional information such as specific FPMs, this internal is 
negotiation process is repeated. Note that when the 
start time for a group arrives, responsibility for it is trans- 
ferred from the Reservation Manager 72 to the QOS 
Manager 70. 

High-Level Features 

In the present invention, each user can associate , 
QOS requirements with data being presented at his/her 
terminal. These requirements cover both the temporal 2S 
and informational properties of CM. For video, informa- 
tional properties include: (1 ) number of images per sec- : 
ond; (2) image dimensions, including pixel depth; (3) im- 
age quality, including (a) quantization factor; (b) move- 
ment threshold; (c) ratio of intra to inter coded images; 30 
and (4) loss measure. Similar informational properties 
can be defined for audio. Temporal properties are delay 
and jitter. 

A user might set these variables in a static fashion 
or have the ability to dynamically alter them during pres- 3S 
entation. Depending on the interface, access to these 
variables might be quite explicit, but is more likely con- 
trolled via one or two overall quality measures for the 
channel. This could take the form of a graphical slider 
or perhaps a choice of high, medium and low qualities. *o 
This creates a distinction between application and sys- 
tem level QOS specifications. System level specifica- 
tions are what the bridge and network understand, e.g., 
bandwidth, delay, etc. Application level specifications, 
on the other hand, must be translated by the client ap- *s 
plication software to the system level representation. 

-The system of the present invention is sink-driven 
in the sense that the user is empowered to influence the 
desired QOS for its incoming channels. This approach 
allows considerable flexibility, relying on the bridge serv- so 
ice API to make changes to channel attributes (data 
structure parameters, e.g., QOS). Client requests indi- 
cate a desire to alter activities at the bridge 10 and they 
may be denied because of a lack of resources. Each 
client of the bridge service 60 is required to maintain a ss 
callback interface. This is used to inform the' client of 
events (e.g., new client joining) and errors. It is also 
used to request that the client change its resource us- 



age, for example, by using less bandwidth, This is im- . 
portant because QOS-driven systems rely on statistical 
multiplexing for efficient resource sharing, and conse- . 
quently' there may be occasional periods of resource 
^overload. Such, is particularly the- case' .when dealing 
with the potentially large bandwidth range' of variable bit 
rate video. 

QOS requirements which exist at a higher level than 
those of individual channels are also supported. In par- 
ticular, it is useful.to be able to reason about QOS at 
each of the independent levels: channel,; client and 
group. The present invention supports the ability to deal 
with : resource allocation and: overload in terms of these* 
levels. Using the API to set attributes, an authorized cli- 
ent is allowed to .set resource J imits and install simple 
policies for ^dealing with contentions Resource limits, 
cost limits,, degradation policies, eta are controlled by 
parameters stored in varibus?additional, fields of the as- 
sociated client, group, or chamnehdata structure. As with 
all parameters; they, may: be passed along with the call 
to create a client, . group, or channel. Alternatively, they 
may later be passed using the set attribute call; v 

In general, degradation. policies may ba set by cli- 
ents or the bridge >operator,:and areMmplemented by 
software in the QOS Manager,70. fror; example, priori- 
tiesvcan be assigned tofchannels so that; for example, 
a client could specify that video~should-:be degraded in 
preference tb-audio. SimHar; policies ean. be provided at 
the ^group. level: For example;, managerial groupconfer- 
ences can be assigned a higher priority than those 
groups running game software;: Also, price related infor- 
mation might be used when setting degradation priori- 
ties, e.g., the lowest priced service is the most likely to 
be degraded. • ~ c * 

Relationships between entities (e.g., channels) at 
the same level may also be specified in terms of QOS, 
for example, the degree of interchannel synchronization 
(i.e., lip synching). Coarser grain resource allocation is 
also supported so that, for example, the bridgaoperator 
could specify that fifty percent of the bridge resources 
may be allocated to a particular group. 

The bridge also keeps track of accounting (e.g., 
how much of the CPU is group A using?) and, pricing 
information. These functions may support several of the 
" above-mentioned high-level features;: 

The FPM/flow model of the present invention could 
also be adapted to provide QOS support on a multime- 
dia terminal 12. Such a feature would allow, axlient to 
negotiate for the multimedia terminal resources and es- 
tablish a QOS contract with the multimedia terminal 12. 
FPMs provided, by the terminal 12 might include data 
capture. (e.g., video capture by a camera and audio cap- 
ture by a microphone) and data presentation- (e.g., video 
display by a CRT and audio display by a speaker), and 
data compression/decompression (this function could 
alternatively be performed by the bridge 10). In a similar 
manner, the present invention could be adapted to sup- 
port QOS in other types of network-based servers^^., 
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video-on-demand servers). 

To those skilled in the art to which the present in- 
vention pertains, many changes in construction and var- 
iant embodiments will be suggested without departure 
from the spirit and scope of the present invent ion. 



Claims 

1 . Ah electronic bridge resource management system, 
comprising: ~ 

- a programmaticaily-implemented processing 

- ^ ; .system having: . j . 

" a bridge se rvice'thar interfaces with,a plurality 
■ ■"• ol clients, where* said bridge service receives a 
^ " quality of service- (QOS) specification from 

- r t. each-ots&id clients and 

"V < a resource manager that receives said QOS • 

"specification from said bridge^ service, distrib- 
;i»r'; utes at least one QOS constraint associated 
with. : said QOS specification ^across . flow 

- ? /^processing modulss of a channel,, determines > 
\<i u resource requirements for eacrr of;said flow 
•he ^processing' modures/.and determines- whether 
.c'QiT bridge resources can be allocated to meet said. 

oi.iQOS specification; i j *.i -i v* *k : • h"» :•. 
where in~said clients may after tfoeirQOS spec- ^ 

- k ificatiogs and retry, if said resource manager de- 
>j :nies them<admission because, of a lack of avail- 

-* Stable bridge resources. /.*. ...-j.it- - 
-.•ci'G » i -.t.„ j .;>:*,:*"; j 

2. -Trje system of claim 1," wherein each said client is 
a program running at a multimedia terminal. 

3. The system of claim A or claim 2, wherein said 
processing system is implemented on a single host. 

4. rThe system of claim 1 or. claim 2, wherein said 

- processing-system is implemented on a plurality of 
distributed hosts., * . j - - 
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The system c( any.olthe preceding claims, wherein 
said flow processing modules perform functions in- ; 
eluding combination; transformation,; andsynchro- 4$ 
nization. ; 'i; ;^ . - •„ ; i 



The.systemoiany.of the preceding claims, wherein 
said flow processing modules are: interconnected 
by tows for data transport. * r . 



7. - The system of any of the preceding claims, wherein 
.said processing system maintains- group, client, 
-channel, FPfvVthread, and flow data, structures. , 

8. - The system of claim 7, wherein said FPM/Jhread da- 

ta structure, includes a list of resource handles, 
where said resource handles .entitle the associated 
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flow processing module to specific bridge resourc- 
es. 

9. The system of claim 8, wherein said bridge resourc- 
es include memory, CPUs and DSPs; ' 

10. The system of any of the preceding claims, wherein 
said. QOS specification includes parameters indi- 
cating type of contract, traffic, and performance. 

11. A method for managing computer system, resourc- 
es, comprising the steps ofj ■ ' , : . ' ! 

passing a quality of service (QOS) specification 
to a computer system; • ■ \ f \ 
said computer system associating estimated 
computer system resources to channel 
- processing activities based upon constraints 
derived from said QOS specification; 
said computer systems granting or denying ad- 
mission to computer systems resources de- 
pending on availability of said computer sys- 
tems resources; and 

altering said QOS specification and i retrying if 
. admission is denied. 

12. The method of claim 11, wherein said computer sys- 
tern is a server. 

13. The method of claim 12, wherein said server is a ^ 
bridge. 

14. The method of any of claims 11 to 13, wherein the * 
step of passing a quality of service (QOS) specifi- 
cation includes the substeps of: 

a user specifying a high-level application QOS 
specification; and 

translating said application QOS specification 
to a low-level system QOS specification. 

15. The method of any of claims 11 to 14, wherein the 
step of associating estimated computer system re- 
sources to channel processing activities includes 
the substeps of:' 

performing QOS constraint distribution across 
• . a set of flow processing modules asociated with 
said channel processing activities; and' . 
determining resource requirements for each 
flow processing module. 

16. The method of any of claims 11 to 15, further com- 
prising the steps of: 

- . ■ instantiating flow processing modules and as- 
signing said flow processing modules to threads for 
'execution. 
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1 7. The method of claim 1 6, further comprising the step 1 
of: 

after a client is admitted to join a channel, a l f i 
resource scheduler selecting a thread for execution i V 
from amongst a queue of. said threads according to s 
a scheduling policy. , 

18. The method of any of claims 11 to 17, further com- 
prising the steps of: .! ■ 1 

a reserver passing to said computer system a ''■'.> 
create group request specifying a future start r \ • | 1 
time 'and future requirements of said group; • 1 • » , 
translating said request resource estimates; 
checking to determine any overlap with current' T's, , . 
resource allocations; ' . . ' < 

sending a reply to said reserver indicating 1 
whether the necessary resources will be avail- 
able. ■ . 1 

; 20 

19. The method of any of claims 11 to 18, wherein the 
step of granting or denying admission further in- 
eludes the step of determining whether client spec- , 
ifted resource limits would be exceeded. 

' . 25 . i 

20. The method of claim ,1 1 , wherein said computer sys- 
tem is a terminal. > ■ 

21. A method for implementing a bridge degradation 
policy, comprising the steps of: 30 

a client passing service degradation policy in- 
formation to a bridge, where said degradation 
policy information relates to a prioritization 
amongst clients, channels, or groups; - as 
said bridge storing data corresponding to said 
degradation policy information in a client, chan- 
nel or group data structure; and . „ _ . 
said bridge implementing said degradation pol- 
icy should ai bridge resource overload occur. 40 

22. The method of claim 21, wherein said degradation 
policy specifies that a video channel should be de- 
graded in preference to an audio channel. 



23. The method of claim 21, wherein said degradation 
policy utilizes resource price related information. . 



45 



so 



ss 



10 




BNSDOCID: <E P 0774878A2_L> 



11 



EP 0 774 878 A2 




Figure 3 



BNSDOCID! <!EP U774B7BA2 I * 



12 




BNSDOCID: <EP__0774878A2_I_> 



13 



EP 0 774 878 A2 




14 



DientA C&entB 



ClientC 



Bridge Svc. 1 QOS Mgr. Reservation Mgr. Combination CtJr. 



create 
diem 



create 

group 



create,^ 
channel; 



)otn^ 
channeU 



0) 



(2) 



(3) 



W ".4 



create 

client 

join 
group 

join 
channel 



(10) 



create 

client 



join 
group 

join 
channel 



<5) 



(8) 



(6) 



(7) 



Figure 7 



BNSDOCID: <EP 0774878A2_I_> 



15 



(19) 



Europaisches Patentamt 
European Patent Office 
Office europeen dee brevets 



< 11 >, 



(12) 



(88) Date of publication A3: 

06.08.1997 Bulletin 1997/32 

(43) Date of publication A2: r 
21.05.1997 Bulletin 1997/21 * 

(21) Application number: 96308028.8 

(22) Date of filing: 05.11.1996 ' 



EP 0 774 878 A3 

EUROPEAN PATENT APPLICATION ,' , , 
(51) lntCI.6: H04Q 11/04 



(84) Designated Contracting States: 


(72) Inventor: Sreenan, Cormac J. 


DEFRGB ' 


i Green Village, New Jersey 07935 (US) 


(30) Priority: 17.11.1995 US 560446 


• f '. ■ • 
(74) Representative: 


1 i 

(71) Applicant: AT&T Corp. 


Watts, Christopher Malcolm Kelway, Dr. 


Lucent Technologies (UK). Ltd, 


New York, NY 1 001 3-241 2 (US) 


5 Mornlngton Road 


i 


Woodford Green Essex, IG8 0TU (GB) 



(54) Resource management system for a broadband multipoint bridge 



(57) An electronic bridge resource management 
system, having a programmatically-implemented 
processing system. A bridge service interfaces with a 
plurality of clients and receives a quality of service 
(QOS) specification (4) from each of the clients. A re- 
source manager receives a QOS specification (5) from 
the bridge service, distributes at least one QOS con- 
straint associated with the QOS specification across 
flow processing modules of a channel, determines re- 
source requirements for each of the flow processing 
modules, and then determines whether bridge resourc- 
es can be allocated to meet the QOS specification. The 
clients may alter their QOS specifications and retry if the 
resource manager denies them admission because of 
a lack of available bridge resources. 



CO 
< 
00 

00 



O 

a. 

LU 



Printed by Jouve, 75001 PARJS (FR) 



BNSOOC1D: <EP 077487BA3_I_> 



EP 0 774 878 A3 



j) 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



*■ Application Number' V - 

EP 96 30' 8028 i 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages |_ ' 



Relevant 

to claim 



CLASSIFICATION OF THE 
APPLICATION (lntClo) 



X 
Y 



Y 
A 



WO 94 248G3 A (AT & T CORP) 27 October 
1994 , 

page 9, line 8-29 * 
page 13, line 17-26 * 
page 15* line 26-31 * 
page 20, line 10-23 i 
page 26, line 18 - page 27, line 17 * 
page 28, line 34 - page 29, line 11 * 
page 29, line 24-30 * 
page 30, line 2-10 * 
figures 1,2,6 * ■[ 
page 31, line 11-17 * . j - 

SERVING HUMANITY THROUGH COMMUNICATIONS. 
SUPERCOMM/ICC, NEW ORLEANS,: MAY 1 - 5, 1 
1994, 

vol. VOL. 1, no. 1 May 1994, INSTITUTE 
OF ELECTRICAL AND ELECTRONICS ENGINEERS, 
pages 160-164, XP000438902 
DUBOIS D ET AL: "A QOS SELECTOR FOR 
MULTIMEDIA APPLICATIONS ON ATM NETWORKS" 

* figure 2 * 

* abstract * 

* page 160, column 1, line 22-23 * 

* page 162, column 2, line 4-22 * 

* page 162, column 2, line 37 - page 163, 
column 1, line 1 * 

-/-- 



The present search report has been drawn up for all claims . 



-6, 
1t13, 
15.18.2G 
10 



H04Q11/04 



i.' .1 



11-15, 
18-20 ' 



TECHNICAL 
SEARCHED 



FIELDS 
(lnta.6) 



16,17 

1-18 



H04Q 



e 
I 
a 

8 
8 

i 



THE HAGUE 



Dtfe of aunpletloa td the war* , i . 

7 March 1997 



Dhondt, E 



CATEGORY OF CITED DOCUMENTS 

' X : particularly relevant If taken alone 
, Y : particularly relevant if combined with' another 
document of tbe same category 

A : technological background 

O : non-written disclosure 

P : Intermediate document 



T : theory or principle underlying the invention 
E : earlier patent document, hot published on, or 

if ter . the filing date 
"D : document cited in the application 
L : document dted for other reasons 



: member of the same patent family, corresponding 
document ,., „ , - . . 



BNSBGSIDi «EP. 9774878A3 J_J- 



2 



EPjO 774 878 A3 



S\ European Patent 

wn 0f,ice 

I CLAIMS INCURRING FEES 



The present European patent application comprised si the lime of filing more than ten claims. . 



□ 



All claims fees have been paid within the prescribed time limit The present European March report has been i 
drawn up tor all claim*. 

Only pari of the claims fees neve been paid within the prescribed time limit The present European search 
report has been drawn up for the first ten claims and for those claims tor which claims fees have been paid. 

namely claims: 



1 No claims fees have 0060 p,ld "ttnta the prescribed time limit The present European search report has been 

orawn up tor the first tan claims. 



LACK OF UNITY OF INVENTION ! 



Tne Search Division considers that the present European patent application does not comply with the requirement of unity of 
imjertiion and relates to several Inventions of groups of Inventions. .... 
namely: r L ~ . , 

; See sheet ' . - . - , 

i . ■* ■ - - . 



| — | AH further search fees have been paid within the fixed time limit The present European search report has 
been drawn up for all claims. 

Q On\y pert of the further search fees have been paid within the faed'timelimlt. The "present European search 

report has been drawn up for those parts of the European patent application which relate to the Inventions in 

respect of which search fees have been paid. 

! 

^namely claims: 



f)3 None 01 ,he ^rinsr »oarch fees has been 'paid- within the fixed time Hmlt The present European search report 
has been drawn up forjrjpse parts f ot the European patent application which relate to the invention first 
mentioned in the claims, «.->....-..*■- , 

namely claims:" "I *"*~ 2.Q 1 ".,""'"*,' 



BMSDOCJD: <EP 0774878A3_l_> 



3 



EP 0 774 878 A3 




European Patent 
Office 



EUROPEAN SEARCH REPORT ' 



I 1 Application Number 

EP 96: 30, 8028 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages ' 



COMPUTER COMMUNICATIONS REVIEW- ' / 

vol ,,22, no. 4, 1 October 1992', 1 ■ 
pages 88-98. XP000371836 
HIDEYUKI TOKUDA ETAL: "CONTINUOUS MEDIA 
COMMUNICATION WITH DYNAMIC QOS CONTROL 
USING ARTS WITH AN FDD! NETWORK" ... i 

* paragraph 2.2 * ' , ' 

* page 91, column 1, line 35-45 * , , 

* page 91, column 2, line 26-31 * 
paragraph 3.4 * 

HIGH PERFORMANCE NETWORKING 6, IFIP 6TH. ( 
INTERNATIONAL CONFERENCE ON HIGH' 
PERFORMANCE, NETWORKING (HPN). PALMA DE 
MALLORCA, SEPT. 13 - 15 f 1995, 
no. CONF. 6, 11 September 1995, PUIGJANER 
R (ED ), , 
pages 85-100, XP000624329 
NGUYEN HONG QUANG ET AL: "SYSTEM SUPPORT 
FOR DISTRIBUTED MULTIMEDIA APPLICATIONS 
WITH GUARANTEED QUALITY OF SERVICE" 

* figures 3,4 * 

* page 92, line 4-20 * 

IEEE TRANSACTIONS ON COMMUNICATIONS, 
vol. 39, no. 12, 1 December 1991, 
pages 1875-1885, XP0O0268155 
V0NDERWE1DT G ET AL: "A MULTIPOINT 
COMMUNICATION SERVICE FOR INTERACTIVE 
APPLICATIONS" 

* abstract * 

* page 1877, column 2, line 54 - page 
1878, column 1, line 26 * 

* page 1878, column 2, line 17-44 * 



Relevant 
to cftaim 



CLASSIFICATION OfrVTHE 
APPLICATION (lntXL6) 



7-10,16, 

17 , 



8,9 V 
11-20^ 



1-20 



TECHNICAL FIELDS 
SEARCHED , „ . a« CL6) 



The present search report has been drawn up for all claims 



1.13 



riaea«<i 

THE HAGUE 



Data of coifUtko* of thft Marc* 

7 March 1997 



Dhondt, E 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant if taken alone 

Y : particularly relevant if combined with another 

document of the same category 
A ; technological background 
. O : non-written disclosure. 
P : intermediate 4 



T : theory or principle underlying the Invention 
E : earlier patent document, but publish ell on, nr 

after the filing date 
D : document cited in the application 
L : document died for other reasons 

4 : member of the same patent family, corresponding 



4 



EP 0 774 878 A3 



EuropGan Patent 
Office 



96308028.8 



B 



I LACK OF UNITY OF - INVENTION j 



Tha S«vci Oivuicn caru«j«rs rai r.« Draaf^t European paunt aopcaoon ooas not czm&y win tn* raoinr«m*ni of lintiy of 
inv»ftoon anc ra>aias aa i uvtraJ urf noons or ^rount ct inyvnoons. ' - ' * ' . * ' 

nafriwy; *..*'.-*_.. 



1 . Claims : 1 -20 : A resource management method and system 

i . .* ' 

2. Claims : 21-23: A method for implementing a service degradation policy in a 

bridge. ; 1 • 




BNSDOCJD: <EP 077487BA3_I_> 



5 



EP 0 774 878 A3 



European Patent 
Office >i ' 



EUROPEAN SEARCH REPORTi 



I 1 Application 1 

EP 96 30 8028, 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, ■ 
of relevant passages 1 



IEEE NETWORK: THE MAGAZINE OF COMPUTER - 
COMMUNICATIONS, ' ' 1 ' , 

vol, 6, no. 1, 1 January 1992, , ' 

pages 26-35; XP0002622GO 
PEHRSON B ET AL: "DISTRIBUTED MULTIMEDIA 
APPLICATIONS ON GIGABIT NETWORKS" t 
* page 31, line 60-65 * 



18, 



I !' 
1 ■ I 



Relevant < 
to daim 



CLASSIFICATION OF THE 
APPLICATION (lnt-CLC) 1 



The present search report has been drawn up for all claims 



TECHNICAL FIELDS 
SEARCHED (InLO.6) 



Plate of % 

THE HAGUE 



Dalt of coa*lttiaa of the ware* 

7 March 1997 



Dhondt, E 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant If taken alone 

Y : particularly relevant If combined with another 

document of the same category 
A : technological background 
O : non-written disclosure 
. P : Intermediate < 



T : theory or principle underlying the invention 
E : earlier patent document, but published on, br 

after the filing date 
D : document dted in the application 
L : document cited for other reasons 



£ : member of the same patent family, corresponding 



6 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



BEST AVAILABLE IMAGES 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 



□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: . 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 




BLURRED OR ILLEGIBLE TEXT OR DRAWING 



Wis Page Blank (uspto) 



